Skip to content

fix(http): verify upstream certs for client-auth destinations (GHSA-p5c5-p2gx-h6q6) - #1255

Merged
tommysitu merged 1 commit into
masterfrom
fix/client-auth-tls-verification-ghsa-p5c5-p2gx-h6q6
Nov 1, 2026
Merged

tommysitu merged 1 commit into
masterfrom
fix/client-auth-tls-verification-ghsa-p5c5-p2gx-h6q6

Conversation

@tommysitu

Copy link
Copy Markdown
Member

Summary

  • With client authentication configured and no -client-authentication-ca-cert, upstream connections set InsecureSkipVerify: true and accepted any server certificate. -tls-verification was ignored on this path.
  • Without a CA cert, the system root CAs are now used. InsecureSkipVerify follows -tls-verification, same as the default client.
  • Updated the SSL docs to describe this.

Test plan

  • go test ./core/... -count=1
  • New core/http_test.go against a TLS server that requires a client cert, covering verification on and off, with and without a CA cert
  • The no-CA and verification-disabled tests fail without the fix and pass with it
  • go vet

🤖 Generated with Claude Code

…5c5-p2gx-h6q6)

When a destination matched -client-authentication-destination and no
-client-authentication-ca-cert was given, the upstream client was built
with InsecureSkipVerify: true, so any server certificate was accepted.
The -tls-verification flag was ignored on this path in both cases.

Leave RootCAs nil when no CA cert is given so the system roots are used,
and set InsecureSkipVerify from -tls-verification like the default client.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@tommysitu
tommysitu merged commit fa45f65 into master Nov 1, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant